Delayed fork proposals #89
Conversation
josojo
force-pushed
the
delayedForkProposals
branch
from
9694cb9 to
f15b4cb
Compare
contracts/ForkingManager.sol
Outdated
| @@ -80,7 +50,8 @@ contract ForkingManager is IForkingManager, ForkableStructure { | |||
| address _parentContract, | |||
| address _globalExitRoot, | |||
| uint256 _arbitrationFee, | |||
| address _chainIdManager | |||
| address _chainIdManager, | |||
| ForkProposal[] calldata proposals | |||
There was a problem hiding this comment.
I wonder if we really need to manage this here. I'm thinking the ForkingManager just refuses to fork if it's already in the preparing-to-fork state, and then we leave it up to the caller (which I imagine as a reality.eth Arbitrator contract or similar that has already put the thing being disputed in a frozen state) whether it wants to wait until the fork completes and retry, or cancel the arbitration process, return the fee and only retry if the user requests a retry.
There was a problem hiding this comment.
I think if we really wanna have different "preparation times" for the fork, then we need. Imagine, there is a fork scheduled with 1 month "preparation time" and then a "fast forking" schedule is also hit.
I am not 100% we need different time, but I think its the complexity is not too much to include different times.
There was a problem hiding this comment.
I don't really think we want different times, since the whole ecosystem has to fork so it affects everyone.
There was a problem hiding this comment.
Just to add, you shouldn't be doing fast-forking of the main ledger, because users can't keep up with it. If you want fast-forking you should use an L3 that specifically expects to be doing fast-forking, for example because it's mainly used by bots or traders or some set of users that can handle this happening.
josojo
force-pushed
the
delayedForkProposals
branch
from
f15b4cb to
3f55141
Compare
This PR allows to submit delayed/scheduled fork proposals.
I image that each adjudication framework will enforce its own delay and hence, we don't enforce a specific number.
The main concern about this implementation is that different delays might cause overlapping scheduled forks. This implementation copies the forkschedules then just to the new forking managers. This is okay, as different forks should be scheduled to remove different courts.(This could be enforced by outside non-core helper contracts at the submission time of the tx.